home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 November / EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso / earcd / program / amos / amoslist.lzh / AMOSLIST / 000314_amos-request@svcs1.digex.net_Fri Sep 22 16:35:14 1995.msg < prev    next >
Internet Message Format  |  1995-10-02  |  4KB
  1. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id QAA23684;  for <mcox@access.digex.net> ; Fri, 22 Sep 1995 16:35:13 -0400
  2. Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id OAA17324 for amos-out; Fri, 22 Sep 1995 14:42:14 -0400
  3. Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id OAA17321 for <amos-list@svcs1.digex.net>; Fri, 22 Sep 1995 14:42:13 -0400
  4. Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id OAA09289;  for <amos-list@access.digex.net> ; Fri, 22 Sep 1995 14:41:41 -0400
  5. Received: from post.demon.co.uk by disperse.mail.demon.net id aa13529;
  6.           22 Sep 95 15:04 +0100
  7. Received: from westmead.demon.co.uk by post.mail.demon.net id aa25126;
  8.           22 Sep 95 15:00 +0100
  9. From: Mark Carter <Mark@westmead.demon.co.uk>
  10. Organization:  None Whatsoever
  11. To: amos-list@access.digex.net
  12. Date:          Fri, 22 Sep 1995 14:56:33 +0000
  13. Subject:       Re: Update me....
  14. Priority: normal
  15. X-mailer: Pegasus Mail/Windows (v1.22)
  16. Message-ID:  <9509221500.aa25126@post.mail.demon.net>
  17. Status: RO
  18. X-Status: 
  19.  
  20. >     To Mark Carter (I think!).  Its the problem with the arrays.  Using arrays
  21. > does make code easier to read and follow through.  For memory requirements and
  22. > saving information to disk you're better off using the (P/D/L)oke - (P/D/L)eek
  23. > alternative.  It is slightly harder to use initially, but you will save a hell
  24. > of a lot of memory and data access will be a hell of a lot quicker.  I know
  25. > this from past experience with large arrays.  If arrays are too large
  26. > (100,100) for example, then AMOS Creator crashes.  I don't know with AMOS Pro.
  27. > It is definitely worth perservering with the data banks way.
  28.  
  29. The memory saving I would achieve in my program would be about 30k, 
  30. which I dont think is that much considering I am writing it for a 2 
  31. meg machine.  I already use the P/D/L(oke/eek) to save/read info from 
  32. disk - its just that at the start of the proggie I load them all into 
  33. memory wasteful arrays.
  34.  
  35. Here's why I'm not so sure reading directly from a bank is the "nice" 
  36. way to do things:
  37.  
  38. Say, I have 10 teams (20 players each) with data - one component is a 
  39. 25 character long string giving the player name.
  40.  
  41. Array method:
  42. At start of prog, load in names from bank into NAME$(20,10), etc
  43. During prog,
  44. NAME$=NAME$(Player(1 to 20),Team(1 to 10))
  45. .....[occurs lots of times in progs]
  46. If I make a change to the format of the bank (e.g need to allow for 
  47. longer player names) all I need to do is change the start of the prog 
  48. where data is read in from the bank.
  49.  
  50. Bank method:
  51. Nothing at start of prog (except smaller Set Buffer size :-))
  52. During prog,
  53. NAME$=Peek$(Start(Bank Num)+1000*Team+50*Player,25,Chr$(0))
  54. ....[occurs lots of times]
  55. (Note - is this really that much faster than arrays considering the 
  56. calculations to find the address of the string?)
  57.  
  58. Now, if I make changes to the bank I need to change every occurence 
  59. of where I access player names etc, and there is no search which 
  60. would do this. Therefore, I would manually need to search through the 
  61. whole program - which would not be pleasant if the code is over 300K 
  62. long and not only do I have to access names, but other data too!
  63. The bank method would also be more prone to mistyping errors due to 
  64. its more complicated format.
  65.  
  66. -------
  67. I think the jury is still out on this one.
  68.  
  69. Of course one solution (similar to the one Ben suggested) would be to 
  70. define a procedure:
  71.  
  72. Procedure _GET_NAME[Player,Team]
  73. End Proc[Peek$(Start(Bank Num)+1000*Team+50*Player,25,Chr$(0))]
  74.  
  75. During prog,
  76. _GET_NAME$[Player,Team]
  77. NAME$=Param$
  78.  
  79. IMHO this would be the best compromise (but still messy)
  80.  
  81. Why shouldn't Amos interpret the line:
  82. NAME$=_GET_NAME$[Player,Team]
  83. in exactly the same way?.... it would solve all (or most) of our 
  84. problems.
  85.  
  86. But (yes another but) with all the different types of stats I use, I 
  87. would need to have lots of these procedures messing up my flawless 
  88. code ;-) (although I could only use this method on the more important 
  89. arrays...)
  90.  
  91. Gimme some feedback............................please!
  92.  
  93. Gotta go - my fingers are starting to hurt!
  94.  
  95. Cheers,
  96.  
  97. Mark
  98.  
  99. Mark Carter
  100. e-mail: mark@westmead.demon.co.uk,   exet0007@sable.ox.ac.uk